【レポート】Chaos Engineering が合うもの/合わないもの – ChaosConf2019 recap –

#レポート

#勉強会

森亮介

2019.11.12

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Chaos Engineering が合うもの/合わないもの

2019年11月11日（月）に、アマゾンウェブサービスジャパン株式会社主催の「ChaosConf2019 recap」が開催されました。

ChaosConf2019 recap

ChaosConf2019というのは、Chaos Engineering のサービスを展開する Gremlin 社主催のカンファレンスで、このイベントでは Chaos Engineering に取り組む多数の企業がこれまで、そして現在の取り組みについて知見や経験を披露しました。

本記事では、畑史彦氏によるセッション「Chaos Engineering が合うもの/合わないもの」をレポートします。

登壇者

Amazon Web Services Japan K. K. 畑史彦氏

Solutions Architect

登壇スライド

掲載可能な状態になった時に更新します

レポート

どんな業界やシステムに向いているのか、

向いている業界

どんな業界と相性がいい？
- ChaosConf2019登壇企業の統計から見ると、IT企業だけが活用しているわけではない
- ECをやっている企業、小売業界と相性がいい

なぜECとの相性が良いのか？というと、以下の項目が当てはまるからと言われていました。

可用性が事業の収益に直接的に影響する
比較的ボラティリティの低い事業モデル
- ボラティリティ: 銘柄の価格変動の大きさを示す変動率です。価格の変動幅が大きいほどボラティリティが高く、変動幅が小さいほどボラティリティが低くなります。
サービスがx時間ダウンすると、y円の機会損失
ECではないですが、UberもChaos Engineeringを行なっています
- 彼らは uDestroyという独自のツールを使っているとのこと
  - NetflixのChaos Monkeyをインスパイア
  - 1000を超えるマイクロサービス群、オンプレミスもある
あと、意外に多いのが金融業界
- ChaosConfの会場でGremlinの人と話してわかった
- 銀行などの金融機関も入れば、FinTechと呼ばれるハイテク金融プレイヤーも入る
- 事例は表に出て来にくい

マイクロサービス or モノリス

マイクロサービス：

個々のサービス間でFailureの影響を分離しやすい
Chaos Experimentの実施の調整においても、小さい粒度のチームになりがちなので、文化を根ずかせることがやりやすい
サービス間をまたがったアプリケーションレイヤでのFailure Contextの伝播(レイテンシを増加させるとか)などの仕組みを試みるなら、全体としての統制は必要となる

モノリス:

2000万行を超えたPHPアプリケーションの事例もあります
- モノリスといっても、コンポーネントは分かれている(Web, DB, Cacheなど)
コンポーネント間に対して行う。障害試験に近いやり方で実施できる

Server-based or Serverless

コンピューティングの進化
- 物理マシン、仮想マシン、コンテナ、serverless(AWS Lambdaのような)　というように、時代は流れて来ている。
Server-based
- インフラレイヤへの直接的なFailureのinjectionが可能
  - シャットダウン
  - レイテンシを増加させる
- アプリケーションレイヤーでのFailureも可能
Serverless
- インフラレイヤへの直接的な操作が困難
  - ただ、それはインフラレイヤを意識する必要がないから
  - そもそもそのようなChaos Experimentが必要ないとも言える
- 必然的にアプリケーションレイヤでのInjectionの仕組みが必要になる
より精緻なマイクロサービスレベルでの障害注入を行うため、Netflixは FIT: Failure Injection Testingという手法も用いるようになった
- (Chaos Monkey)インフラレイヤを直接扱うシャットダウンやレイテンシの増加の障害注入はワイルドすぎる時があり、開発者に噛み付いてしまう
  - 影響範囲が大きい
  - 作用範囲を特定の何かに限定しづらい
- (FIT) 例えばあるUAのクライアント端末だけに障害を注入する、テストフラグのあるユーザー通信においてのみ遅延させるなどのアプリケーションレイヤで情報を伝搬させ、アプリケーションレイヤの情報を解釈する
  - 狙ったポイントで極めて限定した範囲に対して行う

Cloud or オンプレ

オンプレミスでのChaos Experiment事例はほぼ見当たらない
そもそも、NetflixがオンプレからAWSに移行した際に猿の軍団を開発、利用したことを詳細に公表したのがChaos Engineeringの大きなターニングポイントであった。
Netflix名言(畑さんが好きな言葉)
- 障害(failure)を避ける最も良い方法は、継続的に障害を起こ(fail)させること
AWSのChaos Experimentに活用できるAPIの紹介
- EC2
  - Stop, Reboot, Kernel Panic
- ElastiCache
  - Stop, Reboot
- ECS
  - Stop Task
- RDS(mysql)
  - Reboot, Failover
- RDS(Aurora)
  - Reboot, Failover, Fault Injection Queries
- Network
  - Switch Security Group, Network ACL Allow/Deny